home *** CD-ROM | disk | FTP | other *** search
/ CD ROM Paradise Collection 4 / CD ROM Paradise Collection 4 1995 Nov.iso / program / swags_z.zip / SOUND.SWG / 0010_SOUNDINF.PAS.pas < prev    next >
Pascal/Delphi Source File  |  1993-05-28  |  12KB  |  290 lines
  1. {
  2. JOE DICKSON
  3.  
  4. > Hello there.. I was just wondering if anyone had any idea
  5. > on how to play a wav/voc File over the pc speaker. I have a
  6. > Program called PC-VOICE, written by Shin K.H. (Is he here?)
  7. > that will play voc's and wav's (whats the difference?) over
  8. > the speaker.. I don't know assembly, just pascal, but I've
  9. > got a friend that can show me how to link the assembly stuff
  10. > in With the Pascal, so that shouldn't be a problem..
  11. > Also, I've tried and failed to find the format of a voc/wav
  12. > File, so if anyone has that, it would be much appriciated.
  13. }
  14.  
  15. Header-- CT-VOICE Header Block
  16. -=-
  17. The header is a data block that identifies the File as a CT-format File.  This
  18. means that you can use the header to check whether the File is an actual
  19. CT-format File.
  20.  
  21. Bytes $00 - $13 (0-19)
  22.  
  23. The first 19 Bytes of a VOC File contain the Text "Creative Voice File", as
  24. well as a Byte With the value $1A.  This identifies the File as a VOC File.
  25.  
  26. Bytes $14 - $15 (20-21)
  27.  
  28. These Bytes contain the offset address of the sample data as a
  29. low-Byte/high-Byte value.  At this point, this value is $001A because the
  30. header is exactly $1A Bytes long.
  31.  
  32. However, if the length of the header changes later, the Programs that access
  33. the VOC data in this File will be able to use the values stored in these two
  34. Bytes to determine the location at which the sample data begins.
  35.  
  36. Bytes $16 - $17 (22-23)
  37.  
  38. These two Bytes contain the CT-Voice format version number as a
  39. low-Byte/high-Byte value.  The current version number is still 1.10 (NOTE--This
  40. may have changed, this was published in 92) so Byte $17 contains the main
  41. version number ($01) and Byte $16 contains the version subnumber ($0A).  The
  42. version number is very important because later CT-Voice format versions may use
  43. an entirely different method For storing the sample data than the current
  44. version.
  45.  
  46. To ensure that the data contained in the File will be processed correctly, you
  47. should always check the File's version number.  if a different version number
  48. appears, an appropriate warning should be displayed.
  49.  
  50. Bytes $18 - $19 (24-25)
  51.  
  52. The importance of the version number is obvious in Bytes $18 and $19.  These
  53. Bytes contain the complement of the version number, added to $1234, as a
  54. low-Byte/high-Byte value.
  55.  
  56. Therefore, With the current version number $010A, Byte $18 contains the value
  57. $29, While Byte $19 contains $11.  This results in the Word value $1129.  If
  58. you check this value and succesfully compare it to the version number stored in
  59. the previos two Bytes, you can be almost certain that you're using a VOC File.
  60.  
  61. This completes the desciprtion of Bytes contained in the header.  Everything
  62. that follows these Bytes in the File belongs to the File's data blocks.
  63.  
  64. The Data Blocks--  The eight data blocks of the CT-Voice format have the same
  65. structure, except For block 0.  Each block begins With a block identifier,
  66. which is a Byte containing a block-Type number between 0 and 7.  This number is
  67. followed by three Bytes specifying the length of the block, and then the
  68. specified number of additional data.
  69.  
  70. The three length Bytes contain increasing values (i.e., the first Byte
  71. represents the lowest value and the third Byte represents the highest).  SO the
  72. block's length can be calculated by using the formula:
  73.  
  74. Byte1 + Byte2*256 + Byte3*65536
  75.  
  76. In all other cases, the CT-Voice format stores values requiring more than one
  77. Byte in a low Byte followed by  a high-Byte, which corresponds to the Word data
  78. Type.
  79.  
  80. Block 0 - end Block
  81.  
  82. The end block has the lowest block number.  It indicates that there aren't any
  83. additional data blocks.  When such a block is reached, the output of VOC data
  84. during the playback of digitized Sounds stops.  Therefore, this block should be
  85. located only at the end of a VOC File.  The end block is the only block that
  86. doesn't have Bytes indicating its block length.
  87.  
  88. +----------------------------+
  89. | STRUCTURE of THE end BLOCK |
  90. |                            |
  91. | Block Type: 1 Byte = 0     |
  92. | Block Length: None         |
  93. | Data Bytes: None           |
  94. +----------------------------+
  95.  
  96. Block 1 - New Voice Block
  97.  
  98. The block Type number 1 is the most frequently used block Type.  It contains
  99. playable sample data.  The three block length Bytes are followed by a Byte
  100. specifying the sampling rate (SR) that was used to Record the Sounds.
  101.  
  102. Calculatin The Sampling Rate-- Since only 256 different values can be stored in
  103. a singly Byte, the actual sampling rate must be calculated from the value of
  104. this Byte.
  105.  
  106. Use the following formula to do this:
  107.  
  108.   Actual_sampling_rate = -1000000 div (SR - 256)
  109.  
  110. To convert a sampling rate into the corresponding Byte value, reverse the
  111. equation:
  112.  
  113.   SR = 256 - 1000000 div actual_sampling_rate
  114.  
  115. The pack Byte follows the SR Byte.  This value indicates whether and how the
  116. sample data have been packed.
  117.  
  118. The value 0 indicates that the data hasn't been packed; so 8 bits form one data
  119. value.  This is the standard Recording format.  However, your Sound Blaster
  120. card is also capable of packing data on a hardware level. (good luck trying to
  121. recreate that)
  122.  
  123. A value of 1 in the pack Byte indicates that the original 8 bit values have
  124. been packed to 4 bits.  This results in a pack rate of 2:1.  Although the data
  125. requires only half as much memory, this method also reduces the Sound quality.
  126.  
  127. The value 2 indicates a pack rate of 3:1, so the data requires only a third of
  128. the memory.  Sound quality reduces significantly.
  129.  
  130. A pack Byte value of 3 indicates a pack rate of 4:1, so 8 original bits have
  131. been packed down to 2.  This pack rate results in A LOT of reduction in Sound
  132. quality.
  133.  
  134. The pack Byte is followed by the actual sample data.  The values contained in
  135. the block length Bytes also indicate the length of the sample data.  To
  136. determine the length of the actual sample data in Bytes, simply subtract the SR
  137. and pack Bytes from the block length.
  138.  
  139. +---------------------------------+
  140. | STRUCTRE of THE NEW VOICE BLOCK |
  141. |                                 |
  142. | Block Type: 1 Byte = 1          |
  143. | Block Length: 3 Bytes           |
  144. | SR Byte: 1 Byte                 |
  145. | Pack Byte: 1 Byte = 0,1,2,3     |
  146. | Data Bytes: X Bytes.            |
  147. +---------------------------------+
  148.  
  149. Block 2 - Subsequent Voice Block
  150.  
  151. Block Type 2 is used to divide sample data into smaller individual blocks. This
  152. method is used by the Creative Labs Voice Editor when you want to work With a
  153. sample block that's too large to fit into memory in one piece.  This block is
  154. then simply divided into several smaller blocks.
  155.  
  156. Since these blocks contain only three length Bytes and the actual sample data,
  157. blocks of Type 2 must always be preceded by a block of Type 1.  So, the
  158. sampling rate and the pack rate are determined by the preceeding block Type 1.
  159.  
  160. +-----------------------------------------+
  161. | STRUCTURE of THE SUBSEQUENT VOICE BLOCK |
  162. |                                         |
  163. | Block Type: 1 Byte = 2                  |
  164. | Block Length: 3 Bytes                   |
  165. | Data Bytes: X Bytes                     |
  166. +-----------------------------------------+
  167.  
  168. Block 3 - Silence Block
  169.  
  170. Block Type 3 Uses a small number of Bytes to represent a mass of zeros.  First
  171. there are the three familiar block length Bytes.  The length of a silence block
  172. is always 3, so the lowest Byte contains a three, and then the other two Bytes
  173. contain zeros.
  174.  
  175. The length Bytes are followed by two other Bytes, which indicate how many zero
  176. Bytes should be replaced by the silence block.
  177.  
  178. This is followed by a Byte that indicates the sampling rate For the silence
  179. block.  The SR Byte is encoded in the same way as indicated in block Type 1.
  180.  
  181. Silence blocks can be used to insert longer paUses or silences in a sample,
  182. which reduces the required data to a few Bytes.  The Voice Editor will insert
  183. these silence blocks through the Silence Packing Function.
  184.  
  185. +--------------------------------+
  186. | STRUCTURE of THE SILENCE BLOCK |
  187. |                                |
  188. | Block Type: 1 Byte = 3         |
  189. | Block Length: 3 Bytes = 3      |
  190. | Duration: 2 Bytes              |
  191. | Sample Rate: 1 Byte            |
  192. +--------------------------------+
  193.  
  194. Block 4 - Marker Block
  195.  
  196. The marker block is an important element of the CT-Voice format.  It also has
  197. three block length Bytes followed by two marker Bytes.  The block length Bytes
  198. always contain the value 2 in the lowest Byte.
  199.  
  200. When the playback routine of "CT-VOICE.DRV" encounters a marker block, the
  201. value of the marker Byte is copied to a memory location that was specified to
  202. the driver.  The marker block is often used to determine where exactly in
  203. playback you are.  This is useful For synchronizing the action of your Program
  204. with the playback, For a Graphical intro For example.
  205.  
  206. Using the Voice Editor, you can divide large sample data blocks into smaller
  207. ones, inserting marker blocks at important locations.  This doesnt affect the
  208. playback of the sample.  However, you'll be able to determine, from your
  209. Program, which point of the sample the playback routine is currently reading.
  210.  
  211. +-------------------------------+
  212. | STRUCTURE of THE MARKER BLOCK |
  213. |                               |
  214. | Block Type : 1 Byte = 4       |
  215. | Block Length: 3 Bytes = 2     |
  216. | Marker: 2 Bytes               |
  217. +-------------------------------+
  218.  
  219. Block 5 - Message Block
  220.  
  221. It's also possible to insert ASCII Texts Within a VOC File.  Use the message
  222. block to do this.  if you want to identify a specific seciont of a sample File
  223. by adding a title, simply add a block of Type 5, in which you can then store
  224. the desired Text.
  225.  
  226. This block also has three block length Bytes.  These Bytes are followed by the
  227. Text in ASCII format.  The Text must contain a 0 in the last Byte to indicate
  228. the end of the Text.  This corresponds to the String convention of the C
  229. Programming language.  This allows you to pring the Texts in a VOC File
  230. directly from memory using the printf() Function in ANSI C.
  231.  
  232. +--------------------------------+
  233. | STRUCTURE of THE MESSAGE BLOCK |
  234. |                                |
  235. | Block Type: 1 Byte = 5         |
  236. | Block Length: 3 Bytes          |
  237. | ASCII Data: X Bytes            |
  238. | end Character: 1 Byte = 0      |
  239. +--------------------------------+
  240.  
  241. Block 6 - Repeat Block
  242.  
  243. Another special Characteristic of the CT-Format is that it's possible to
  244. specify, Within a VOC File, whether specific sample sequences should be
  245. Repeated.  Blocks 6 and 7 are used to do this.
  246.  
  247. Block 6 has three block length Bytes, followed by two Bytes indicating how
  248. often the following data block should be Repeated.  if the value specified here
  249. is 4, the next block is played a total of five times (one "normal" playback and
  250. four Repeats).
  251.  
  252. +-------------------------------+
  253. | STRUCTURE of THE Repeat BLOCK |
  254. |                               |
  255. | Block Type: 1 Byte = 6        |
  256. | Block Length: 3 Bytes = 2     |
  257. | Counter: 2 Bytes              |
  258. +-------------------------------+
  259.  
  260. Block 7 - Repeat end Block
  261.  
  262. Block 7 indicates that all blocks between block 6 and block 7 should be
  263. Repeated.  With this block, several data blocks can be included in a Repeat
  264. loop.  However, nested loops aren't allowed.  The driver is capable of handling
  265. only one loop level.
  266.  
  267. Block Type 7 also has three block length Bytes, which actually aren't necessary
  268. because this block doesnt contain any additional data.  Therefore, the block
  269. length is always 0.
  270.  
  271. +-------------------------------+
  272. | STRUCUTRE of Repeat end BLOCK |
  273. |                               |
  274. | Block Type: 1 Byte = 7        |
  275. | Block Length: 3 Bytes = 0     |
  276. +-------------------------------+
  277.  
  278. We've now described all the different block Types used in VOC Files.  These
  279. Functions are fully supported by the CT-VOICE.DRV driver software.
  280.  
  281. if you'll be writing your own Sound Programs, you should follow this format
  282. because it's easy to use and flexible.  When needed, new block Types are easily
  283. added.  Programs that dont recognize block Types should be written so they
  284. continue operating after an unrecognized block.  This is easy to do because
  285. each Function specifies its own block length.
  286.  
  287. BiblioGraphy: Stolz, Axel  "The Sound Blaster Book", Abacus Copyright (c)1992,
  288. A Data Decker Book Copyright (c) 1992
  289.  
  290.